---
title: "mysql的前缀匹配 + 联合索引优化"
created: 2025-11-25
---
# mysql的前缀匹配 + 联合索引优化

面试官您好，关于“时空衣橱”模块中的关键词搜索优化，我确实做了基于 **MySQL 的前缀匹配 + 联合索引** 这一块优化处理，主要是为了解决模糊搜索性能差的问题。

### ✅ 背景问题：

在最初实现时，我使用的是 `LIKE '%关键词%'` 来做模糊搜索，但这种写法在 MySQL 中是**无法命中索引的**，查询时会进行全表扫描。数据量一旦多了，查询速度就明显变慢，页面响应卡顿。

---

### ✅ 解决思路：改为前缀匹配 + 联合索引

为了提高性能，我做了如下几步优化：

#### 1️⃣ 改写查询语句

一开始我用的是 `LIKE '%关键词%'` 来做模糊匹配，但这种写法 MySQL 是**无法用上索引的**，只能全表扫描，查询一多就很慢。

后来我改成了 `LIKE '关键词%'`，也就是**前缀匹配**，这样就能利用 MySQL B+
树索引的有序性，大大加快搜索效率。

#### 2️⃣ 字段设计上，做了**联合索引**

在服饰表里，我们有字段比如 `name`（服饰名称）、`tags`（标签）、`category`（类别）。

我根据搜索习惯设计了类似 `(category, name)` 或 `(tags, name)` 的联合索引。

比如用户选了“裙子”类别再搜关键词，这时就能利用 `category` 作为联合索引的前缀，直接命中索引查到 `name` 字段，避免回表查询。

这里有个细节：**联合索引字段的顺序非常关键**，必须遵循“最左前缀原则”，我把筛选条件更常用的字段放前面，提升命中率。

#### 3️⃣ 使用 `EXPLAIN` 验证执行计划

我通过 `EXPLAIN` 查看执行计划，确认是否真正用了索引。

优化前是 `type: ALL`（全表扫描），优化后变成了 `range` 或 `ref`，说明走了索引路径，性能提升非常明显。

这套优化下来，在不引入 Elasticsearch 这种搜索引擎的前提下，就把原本几百毫秒的查询延迟降到了几十毫秒，用户体验改善还是比较明显的。

---

### ✅ 扩展策略：保留模糊搜索体验的同时兼顾性能

当然前缀匹配的体验不如全文搜索灵活，所以我也做了一个折中方案：

- 当用户输入两个字以上时使用前缀匹配；
- 输入特别短或模糊性很强时，系统默认推荐热门关键词；
- 后期我们也调研了接入 **全文索引（FULLTEXT）** 或 **Elasticsearch** 来支持复杂搜索，目前项目数据量还未到那个规模，所以暂未采用。

---

### ✅ 总结：

通过前缀匹配 + 联合索引的优化方式，在不接入额外搜索引擎的情况下，实现了搜索性能的大幅提升，查询平均延迟从几百毫秒降到几十毫秒，配合 Redis
缓存之后基本可以秒级响应，满足当前的实际业务场景。